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introduction to 





TCP/IP and 


Embedded Internet (2) 


Part 2: programmino tips 
for TCP/IP stacks in webservers 


By P Stuhlmuller 


The key to the implementation of a mini-webserver is the programming 
of the TCP/IP stack. Although this is strictly defined, there is nonetheless 
a certain amount of variety in actual versions of the TCP/IP stack. This 
article provides recommendations and advice relating to the program- 


ming of TCP/IP stacks. 
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Figure 1. Structure diagram of the information flow of a datagram from the client to the 
server, via two separate LAN s and a gateway acting as a bridge station. 
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Which software modules must be 
present in a webserver? The client is 
a general user of the Internet or 
intranet, and it logs on to the net- 
work using standardised softw are (t- 
online, AOL etc.). After the usual log- 
on procedure, we find ourselves on 
the homepage of the provider, which 
is displayed by the browser. The first 
connection link has thus been built 
up that far, and it remains active. 
From here, we could select our 
embedded webserver as the next 
step. After it has been selected, the 
webserver sends its standard page 
via the network to the client station. 
The selection process includes a test 
of the client ID as a minimal security 
barrier. 

Figure 3 in the first instalment of this 
series shows the general scheme. 
The choice of the correct protocol in 
each situation is of vital importance. 
Figure 1 shows, in simplified form, 
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the key features of the data stream. 
After the information packet leaves 
the server, it arrives at least one IP 
router. The NAP (Network Access 
Protocol) is the form taken by con- 
nection at the physical layer. This 
can be an analogue link or a digital 
link, using ISDN or the relatively new 
ADSL. The second factor that affects 
the structure of the software is the 
hardware nature of the server (indi- 
vidual site or network station). This 
affects the way in which the data for 
an information site are configured. 
To make a data page available on the 
Web, the first thing that has to be 
done is to translate the text version 
into HTML (Hypertext Mark-up Lan- 
guage) format. MS Word 2000 can do 
this readily. What is important is 
how the Web pages should appear 
to the (technically oriented) web- 
server. If precisely aligned texts are 
to be combined with graphics and 
tables, it may be necessary to use 
the new XHMTL standard with the 
CSS (Cascading Style Sheets) exten- 
sion. This makes it possible to con- 
trol text parameters in detail, adjust 
the separations between elements, 
assign colours and draw frames and 
rules — and naturally, with a num- 
ber of selectable ‘click points’. 

We cannot use Windows or Linux as 
the operating system for our web- 
server, since there is no hard disk 
drive in the hardware (as shown in 
Figure 5 in the first instalment). 
However, we could plan to use 
Microsoft Windows CE 3.0 or Wind 
River VxWorks, integrated into flash 
memory that serves as program 
memory. For each of these operating 
systems, there are suitable tools 
available for converting data pages 
into web pages. The web pages are 
generated in advance in a PC and 
then loaded into the flash memory in 
the form of (X)HTML tables. The 
operating system (OS) then treats 
these scripts as data blocks, to 
which it adds currently measured 
data values (measurement values) as 
necessary. These are worked into the 
tables or graphics in such a manner 
that at the end, the browser in the 
client can transform the complete 
data packet into a web page. The 
web page thus contains both fixed 
regions and variables in the web lay- 
out. This takes place purely on the 
application level in the OS or DOD 
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model. Various subsidiary data 
pages can be generated via the start 
page. HTML scripts can be used to 
create simple links (direct links and 
forward connections). How ever, we 
will not go into this subject in this 
article. 


Shall we shake hands? 


The selection process can take place 
at the webserver via HTTP, or ina 
more direct form via FTP (File Trans- 
fer Protocol). An IP address is always 
required. Our primary attention must 
go the selection of the proper protocol 
for the webserver. We have to define 
the type of acknowledgement proce- 
dure that has to be carried out 
among the client, router and server. 
There are connection-based proto- 
cols as well as protocols that require 
only a physical link. The client 
‘Speaks’ first, which means that it 
selects the server. The first set-up is 
not acknowledged. If the selection of 
the (private embedded, not general- 
Internet) server is successful, a vir- 
tual connection can be set up via the 
acknow ledgement message from the 
‘target’, although this is not possible 
with some types of protocols. A vir- 
tual connection is a point-to-point 
connection that is maintained by 
software, with a more or less large 
‘handshaking’ component. It should 
by no means be confused with a 
fixed connection, such as that 
between the two terminals of an 
RS232C link. As noted, the perma- 
nence of the point-to-point connec- 
tion depends on the application. 
The TCP/IP protocols should actually 
be seen as a derivative of RS232C 
(that is, asynchronous). The two ter- 
minals must first be synchronised. 
This takes place using the SYN flag 
(SYN = 1). The mutual exchange 
indicates that it is actually possible 
to set up a connection. The normal 
three-way acknowledgement mech- 
anism (handshaking) relates to set- 
ting up a connection for a datagram. 
Once the first handshake has com- 
pleted with the ACK flag, the actual 
datagram is sent, and then the con- 
nection may be established again, 
depending on the situation. The 
datagram itself is initially not further 
acknowledged, and the connection 
is terminated with the FIN flag (see 
Figure 2). 
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Figure 2. Three-way handshaking between 
two stations, which is generally used in Inter- 
net protocols for establishing and terminating 
connections. 


Large quantities of data are split up into 
Smaller pieces for transmission. The recipient 
can then request the sequence number from 
the sender, and thus the next part of the com- 
plete packet (frame). However, this again is 
very dependent on the particular protocol 
used. 

Now we come to the terms SLIP, PPP, PPTP, 
TCP, UDP, ports and sockets, all of which are 
specialised expressions that designate con- 
nection protocols for the appropriate Web 
applications and the software for the activa- 
tion of these protocols. Port numbers are used 
for identification. The items that are most 
commonly used in programming are sum- 
marised in Table 1. SLIP plays a major role 
here, since with it selection is integrated and 
is sent with the order into the Internet in the 
final datagram. The UDP protocol is prefer- 
ably used in cases where the number of 
return messages should remain small. Return 
messages necessarily arise as a result of 
plausibility testing, but the number of such 
messages is affected by the type of protocol 
used. It must be accepted that errors can 
occur. After a suitable pause when waiting 
for the response, the request may be re-sent, 
or the client may be requested to do so. Even 
TCP does not guarantee a completely error- 
free transmission of the packet data block 
under all conditions, although it has a rela- 
tively high standard of performance. How- 
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ever, it does have very secure handshaking in 
each of the detail-level phases. The amount 
of handshaking must be kept within limits in 
order to prevent the amount of processing 
time from rising to impossible levels. Any- 
thing that can be transmitted with a 99.9% 
probability of being error free does not have 
to be acknowledged, since too much hand- 
shaking will plug up the netw ork. 

The large number of different protocols forms 
a very important component of programming. 
We simply make use of existing, proven facil- 
ities. Using these protocols saves time and 
makes for compatibility. As can be seen from 
the TCP/IP header, they are called via sock- 
ets. 


Datagrams 
and service primitives 


The first thing you need t o know for pro- 
gramming TCP/IP stacks is that a request is 
sent to a particular participant (in this case, 
our webserver) via the network. This involves 
the transmission of a number of data blocks 
in the form of datagrams, including various 
protocol headers for the higher-level proto- 
cols, in the direction of the first communica- 
tion partner (that is, the first accessible Inter- 
net host or router). This service is provided by 
the appropriate point-to-point connection pro- 
tocol. The terminal software that is used 
(there are several possibilities) transfers the 
complete datagram. 

Clearly, all that the protocol stack software in 
the client has to do Is to precisely reconstruct 
this datagram and look after the transfer. The 
communications betw een the two partners is 
one-way at this moment, which means that 
the IP datagram Is transferred without hand- 
Shaking and thus must be considered to be 
somew hat unreliable. From experience, how - 
ever, the probability of an error is negligibly 
Small. That is all for the time being. 

The Internet protocol is specified in great 
detail in the IP datagram. It defines functional 
requirements that are designated as service 
primitives and parameters. These service 
primitives are services that are either located 
in the various layers or are made available in 
the various layers. There are two defined ser- 
vices that are relevant to the IP: the transmit 
service and the receive service. 

The transmit service employs the following 
parameters: source address (Source), target 
address (Destination), protocol, type of ser- 
vice, Identification, not-fragment indicator, 
lifetime value, data length, options and 
finally, the data content. 

The receive service receives the datagram 
and employs the following parameters in the 
process: source address (Source), target 
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address (Destination), protocol, type 
of service, data length, options and 
data content. 

The terminal software remains 
active after the datagram has been 
sent from the client. It waits for a 
return message, which should con- 
tain a response from (our) web- 
server. The data section of the data- 
gram contains the information for the 
webserver that tells it which page it 
Should provide to the client, or in 
other words, which page it should 
send in its response. 

On the side of the embedded server, 
the terminal software Is practically 
permanently active, but it is 
installed such that it requires almost 
no processing time in the idle state. If 
a request from the Internet netw ork 
reaches the webserver, the TCP/IP 
stack executes the receive service 
and responds with its own server 
datagram as part of its transmit ser- 
vice. Depending on the application, 
the socket may remain active after- 
wards or it may be de-activated. 
The meanings of the port numbers, 
together with the sockets, form the 
actual interface to the application 
procedures (also called the A pplica- 
tion Program Interface, or API) for 
the webserver, which in response to 
a request from the client station 
must initiate a data page to be sent 
back. This is of fundamental impor- 
tance for the TCP/IP stack program- 
mer. 


Operating systems: 
VxWorks 
and Windows CE 3.0 


From what you have already read, 
you have probably received the 
impression that TCP/IP is not all that 
simple. However, this is all a matter 
of perspective. If there are not any 
sockets available for our home-made 
monitor program for the microcon- 
troller hardware, the important con- 
sideration is to first choose the ele- 
ments that are actually necessary 
(protocols). These must then be 
selected from (for example) open- 
source code (such as Unix or Linux 
libraries) and integrated into our 
existing microcontroller software 
(monitor program). The search may 
be laborious, but at least it Is 
rewarding. 

On the other hand, if we use an oper- 


ating system that can be installed in 
flash ROM for our webserver project, 
such as Wind River VxWorks, imple- 
mentation is almost child’s play, 
since TCP/IP is already integrated. 
All that we have to do is to call the 
sockets ourselves and make sure 
that we observe the requirements 
and use the appropriate port num- 
bers in the procedure. 
Without question, the ideal solution 
for remote control applications is 
Windows CE 2.12 or 3.0. Windows 
CE is an operating system that has 
been specially designed for control 
tasks, and with which Microsoft 
wants to get a foot in the door of the 
enormous world of industrial appli- 
cations. It supports external control 
(remote access) by implementing 
LAN drivers (Level 2, Data Link 
Layer) as well as wide-area connec- 
tions (Internet and/or wireless). 
The TCP/IP stack, with Winsocket 
management, selection procedures 
and the PPP SLIP CSLIP PAP CHAP 
and TAPI protocols, is obligatory. 
There are various examples of how 
to activate sockets under Win- 
dows CE. Everything is truly made 
easy for the user! 
Windows CE has a Separate plat- 
form generator (platform builder in 
the form of definition and binding 
softw are with many dialogues) that 
takes over the preparatory work for 
many specific cases of Internet 
accesses. It links all the essential 
core elements of the operating sys- 
tem such that the result can be pre- 
cisely adapted to the needs of the 
application. 
Windows CE shows a way to imple- 
ment TCP/IP stacks that certainly 
Should not be ignored for profes- 
sional applications. If by contrast the 
TCP/IP stack is put together from 
Unix and/or Linux libraries, the 
amount of effort may be significantly 
larger. 
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The third article of this series, which will 
appear in the July/August 2001 issue, 
features a practical implementation of a 
TCP/IP stack. 
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Protocols 
and Services 


Meaning 


Serial Line Internet Protocol: supports direct selection via a selection procedure to the Internet or TCP/IP network; does not support 
dynamic IP addressing functions or security facilities; works as anetwork interface to the DOD Reference Model [four-level interface: 
level 4 = application, level 3 = transport, level 2 = Internet, level 1 = network interface (physical transmission) a Ethernet IEEE 803.3, 
Token Ring, FDDI, PPP Frame Relay and X .25]. 


DOD The Department of Defense layer model incorporates TCP and UDP in the transport layer. The application level (level 4) supports the FTP 
Internet Levels |HTTP Telnet, NFS, SMTP NNTP SNMP and DNS protocols. The Internet level (level 2) supports IP ARP DCHP and ICMP as well as RIP 
Protocol Layer and O SPF. 


IPX/SPX IPX/SPX is an Internet/N ovell standard that is equivalent to TCP/IP and is a protocol for the general U nix standard. 


Point-to-Point Protocol: supports direct selection via the TCP/IP header; offers self-identification (authenticity), dynamic IP addressing 
(in contrast to SLIP) and error correction. 


SLIP 





Point-to-Point Tunnelling Protocol: enables the transmission of packets from a private (Separate) network; these are first encrypted and are 


PPTP then effectively transmitted through a ‘tunnel’ in a public network (the Internet). 


File Transfer Protocol: transfers files between clients and servers that also allow a station to be externally controlled via the network or 


IME cable connection. FTP can be executed via TCP ports 20 and 21, even in command-line mode. 


Trivial File Transfer Protocol: the simplest form of data exchange; utilises UDP port 69. TFTP does not support file management, user 


LELE names or passwords for protection, while FTP allows these options. 


User Datagram Protocol: located in the transport layer of the DOD model, it acts as a unidirectional link, for example to directly connect a 
client station to the first (nearest) Internet host computer, but not in a virtual connection (!). It avoids return messages and thus has low 
overhead demands. It is considered to be less reliable than TCP UDP reduces the amount of processing power required from the 
microcontroller. It is primarily usable for non-critical connections in the Web. It does not assume any fixed connections. 


UDP 


Enables the client to function as a terminal station; especially usable with U nix hosts, but not particularly important for an embedded 


TelN ET webserver, 





HTTP Hypertext Transfer Protocol: the transfer protocol of the World Wide Web; typically transfers documents generated in (X)HTML. 


A calling number, defined at the application level, for a particular service that is provided by TCP/IP. Applicable to the TCP and UDP 
protocols. The following are some sample ports: TCP port 21 = FTP port 23 = Telnet, port 80 = HTTP (the Web); 
UDP port 53 = DNS, port 69 = TFTP port 161 = SNMP 


Software interface for a specific combination of an IP address and a port for a specific application in level 4 of the DOD model. 
The socket process or service is a call to the application layer. Sockets remain active on the transmit and receive side as long as the 
connection is maintained. 


Port 


socket 


Classless Inter-Domain Routing: used in supernet models (multiple networks with separate IP addresses) for binding into a network, 
so that the IP address table can be compressed and limited. Reduces the size of the routing tables used by most Internet routers. 


N AT N etwork Address Translation: converts a private network address into a global Internet address with a valid assignment. 
Very important for a webserver located inaLAN. 


Address Resolution Protocol: located in level 2 (Internet) of the DOD model, it looks after translating IP addresses into physical hardware 
ARP addresses; also supported by Windows CE. ARP writes to the addresses of network adapters, such as Ethernet controllers. 
Very important in all LAN connections. 


CIDR 





Internet Control Message Protocol: supports diagnostic messages, especially when a network, host or port is inaccessible. 


soe Used by the Ping command. 


Internet Group Management Protocol: organises groups of nodes and supports diagnostic and control messages in the network; 


ICMP used especially for multicasting applications. 


Retransmission Time Out: in general, timers are activated in the TCP to trigger retransmission of a datagram if they time out, 


RTO since this means that the first attempt was probably unsuccessful. 


Dynamic H ost Configuration Protocol: provides dynamic assignment of a large number of IP addresses from applications for direct use in 
the Internet. It is installed asa DHCP server on Windows NT machines, where it extends the Administrator options. It is important if the 
webserver system has a Windows NT TCP/IP network server installed as an Internet station. 


SMTP Simple M ail Transport Protocol: used by electronic mail messages for transfers between networks. 


Simple Network M anagement Protocol: employed in LAN s as the network manager; 
SN MP may be important for webservers that are integrated in LAN s. 


NNTP N etnews Transfer Protocol: used to send and receive newsgroups (announcements), e.g. U senet. 


DHCP 





Network File Server: allows the file directories of external stations to be linked to a local file system; 


NFS primarily suitable for Unix applications. 


Used especially with connection-based protocols; increases the level of return messages and handshaking. A quasi-temporary software 
connection is established between the client and the server, somewhat like a ‘virtual leased line’. 


Internetwork The linking of several (local) networks to form a single network; not the same as the Internet. 


ISD N Integrated Services Digital N etwork: digital coding on the telephone line. 
ADSL 


Virtual circuit 





Asymmetric Digital Subscriber Line: a telephone line with a high download rate (up to 500 kbit/s) but a low upload rate (up to 50 kbit/s). 


N Local Area Network: an Ethernet or Token-Ring network. 
WAN W ide Area Network: formed by coupling LAN s and network hosts. 
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